This part provides information and instructions for deploying dashboards. It discusses dashboard deployment considerations, dashboard deployment options, steps for deploying dashboards, tasks for managing dashboard data servers and dashboard display servers, and how to manage dashboard security.
There are two types of dashboard deployment:
The section on the Data server and display server discusses some considerations that are relevant to choosing among deployment options.
Local deployments require the use of the Dashboard Viewer desktop application (available on Windows platforms only). End users open locally-deployed dashboards in the Dashboard Viewer, which must be pre-installed locally or on a shared file system. See Building and Using Apama Dashboards for information about using the Dashboard Viewer.
With web-based deployment, the Dashboard Viewer does not need to be installed locally. Dashboards are invoked through a web browser, and are installed on demand, as web pages, so they can easily be deployed across a wide area network, including the internet.
Web-based deployments provide web-based login functionality and use the authentication mechanism provided by your application server. They support authentication customization by allowing you to, for example, configure your application server to use the security realm and authentication service of your choice.
Local deployments include data server login functionality, and support authentication by allowing you to supply any JAAS-supported authentication module as a plug-in to the data server and to the Dashboard Viewer.
GET requests, the effective limit on the length of a user name in a dashboard is approximately 1000 characters.Web-based deployments support role-based dashboard access control, which allows you to associate a role with a deployed dashboard, and to authorize use of the dashboard only for application-server users with the dashboard’s associated role.
Local deployments support dashboard access control by allowing you to use the system security mechanisms in order to restrict access to the deployed dashboard files.
Both types of deployment support DataView access control, which allows you to control who can have which type of access to which DataViews.
With web-based deployments you can secure inter-process communication by enabling HTTPS in the application server. With local deployments you can secure inter-process communication by enabling secure sockets (SSL) in the data server or display server.
With both types of deployment you can secure inter-process communication through the use of secure channels (SSH) and virtual private networks (VPN).
The display server’s minimum refresh latency (5 seconds) is greater than that of the data server. Use the data server for applications that require high-frequency screen updates.
Both types of deployment are highly scalable, since both use the data server or display server to mediate access to correlators.
The dashboard data server and display server can each serve as the gateway through which dashboards can access your applications running on the correlator. Use of these servers provides scalability by obviating client management on the part of the correlator, and provides security by not exposing the correlator directly to clients.
The data server mediates correlator access for local deployments; the display server mediates correlator access for simple thin-client, web-page deployments.
The data server delivers raw data from which deployed dashboards construct the visualization objects that they display. The display server, in contrast, delivers already-constructed visualization objects in the form of image files and image maps.
The display server’s minimum refresh latency (5 seconds) is greater than that of the data server. Use the data server for applications that require high-frequency screen updates.
Managing the data server and display server is covered in Managing the dashboard data server and display server.
Deployed dashboards connect to one or more correlators via a dashboard data server. As the DataViews in a correlator run and their variables change, update events are sent to all connected dashboards. When a dashboard receives an update event, it updates its display in real time to show the behavior of the DataViews. User interactions with the dashboard, such as creating an instance of a DataView, result in control events being sent via the data server to the correlator.
Simple, thin-client, web-page dashboards communicate with the display server via servlets that run on your application server. These servlets are bundled with Apama. You must provide your own Java web application server (servlet container). Typically, you install the dashboard servlets in your existing web infrastructure.
The following image shows the process architecture for thin-client, web-page deployments. Dashboards communicate with your application server, which communicates with the dashboard display server. The display server mediates access to the correlator.
Locally-deployed dashboards communicate directly with the data server.
The following image shows the process architecture for local deployments. Dashboards communicate with the dashboard data server, which in turn communicates with the correlator(s).
You can scale your application by adding data servers to your configuration. Each correlator can communicate with multiple data servers, and each data server can communicate with multiple correlators.
The following image shows the process architecture after you add data servers to your configuration. Each correlator can communicate with multiple data servers and display servers. Each data server and display server can communicate with multiple correlators.
Deployed dashboards have a unique associated default data server or display server, but advanced users can associate non-default data servers with specific attachments and commands. This provides additional scalability by allowing loads to be distributed among multiple servers. This is particularly useful for display server deployments. By deploying one or more data servers behind a display server, the labor of display building can be separated from the labor of data handling. The display server can be dedicated to building displays, while the overhead of data handling is offloaded to data servers. See Working with multiple data servers for more information.
There are two types of activity involved in making dashboards available to end users:
Sometimes these activities are performed by different individuals. In such a case, the dashboard developer must be sure to communicate the following information to the dashboard administrator regarding the dashboards to be deployed:
.war file or .zip file that was generated when the developer prepared the dashboard for deployment..rtv files).Configuring trend-data caching.